In telecommunications signaling networks, global title translation (GTT) refers to the process by which the signaling connection control part (SCCP) called party address (CdPA) in a signaling message is translated into the point code of an intermediate or final destination. In intermediate global title translation, the SCCP CdPA is translated into the point code of an intermediate destination. In final global title translation, the SCCP CdPA is translated into the point code and subsystem number of a final destination.
A node that performs intermediate GTT translates the global title address (GTA) digits in the message to a point code corresponding to a second node and sends the message with a route-on-global-title indication to the second node. The first node may or may not modify the GTA digits before sending to the second node. The second node performs another global title translation, which could be another intermediate GTT, or a final GTT.
The node performing the final GTT translates the GTA digits in the message to the point code and subsystem number corresponding to the final destination node for the message. After translation, the node sends the message route-on-point-code-subsystem-number to the next hop in the routing path. The next hop in the routing path may or may not be the final destination. Although no subsequent GTTs will be performed, the message may be routed through several more nodes before reaching its final destination.
The transaction capabilities application part (TCAP) protocol is used in Signaling System 7 (SS7) telecommunications networks for sending database queries to a service control point (SCP). The SCP provides an interface to local and remote databases that contain subscriber and routing information. TCAP messages can also be sent from one voice switch to invoke functions in another switch in the network. When TCAP is used to query a database, SCCP may be used in conjunction with TCAP to route the message to the appropriate database subsystem.
In some telecommunications networks, SCPs are redundantly provided. That is, multiple identically provisioned SCPs may be present in a network for enhanced reliability and/or for increasing the speed at which SCP services are provided. Each of the redundant SCPs may have a separate point code, and other network nodes may rely on GTT translations to route messages to the SCPs. In such a case, most final GTT translations are performed such that messages will be distributed among redundant SCPs based on any suitable criteria, such as load sharing. Load sharing between redundant SCPs may be equal, for example, if the SCPs have identical processing capabilities. Alternatively, load sharing may be unequal, for example, if one SCP has greater relative processing capabilities. Another reason for unequal load distribution may include providing a high quality of service SCP for subscribers willing to pay for faster SCP access.
Regardless of the reason for distributing messages among redundant SCPs, there may be some cases in which it is desirable to ensure that a message is delivered to a particular SCP. More particularly, certain types of messages are handled more efficiently when sent to an SCP already involved in the associated transaction. For example, when a query is initiated by an SCP, a response to the query can be handled more efficiently if returned to the initiating SCP. Conventionally, however, there is no discrimination performed based upon the type of message being processed. For example, when load sharing is employed, the load sharing algorithm does not process messages differently based on whether the message is a response or another message type. Thus, a conventional GTT load sharing application could result in a message being sent to the incorrect SCP.
Some conventional approaches use a calling party address (CgPA) point code (PC) from a query message to return the response to the query back to the SCP originating the query. Not all network implementations, however, have a point code in the CgPA. Global System for Mobile Communications (GSM) implementations, for example, do not use a CgPA PC in order to provide space for other data. As a result, for GSM implementations, each transaction must be tracked using a transaction ID in the TCAP message to associate specific transactions with a particular SCP. This requires the use of a device that tracks the state of each transaction by transaction ID and associates it with an SCP until the entire transaction is completed.
Tracking individual transactions requires resource-intensive complex operations, thereby increasing overhead for message processing. Accordingly, a need exists for methods, systems, and computer program products for selectively performing GTT translations based on a message type without requiring the tracking of transactions.